為什麼要統一前端技術棧？從混亂走向秩序

四年接案中的前端技術債務
在過去四年的接案經驗中，我使用了前端技術的各種組合：

• 框架混戰：React、Vue都有使用，每個專案的選擇標準不一
• 狀態管理分散：Redux、Vuex、MobX、Zustand 選擇障礙
• 建置工具演進：從 Webpack 到 Vite 各種打包工具
• UI 組件庫混用：Ant Design、Material-UI、Element UI、自製組件並存

這種技術棧分散帶來的問題愈發明顯：

• 升級地獄：每個專案的依賴升級都是一場災難，相依性衝突頻繁
• 組件無法複用：相似的表單、列表、彈窗在不同專案中重複開發
• 開發效率低落：需要在不同框架和工具間切換思維模式
• 維護成本高昂：bug 修復需要熟悉各種不同的程式碼風格和架構

Kyo-System
為了打造可「長期維護、快速迭代、組件複用」的工作室 SaaS 產品，前端技術棧：

• 全端 TypeScript：與後端共享型別定義，消除前後端重複定義
• React 19 + Vite：生態豐富的框架加上打包快速
• ORPC 型別安全：實現前後端型別統一
• 組件系統化：建立 @kyong/kyo-ui 共用組件庫，支援跨專案複用

這次的鐵人賽挑戰也是要讓自己把這個SaaS產品給打磨出來，一邊分享一邊實作。